3 Parts of a Case

Introduction

Each case can be thought of as comprising 3 main portions. Because your evaluation is being done against a checklist of displayed competencies, it is useful (but not perfectly accurate) to visualise your performance on each part of the case as a distinct component.

Clarifying Questions

As soon as you have receive d the case problem, it is best to pause for a few seconds, to understand what you have been told. After that, you should reiterate the problem statement, or better yet, paraphrase it, and ask if you have understood the question correctly. For example, "If I have understood correctly, our client is XYZ corporation, a major player in the ABC space. Our task at hand is to understand why there profits have declined over the last 6 months, and identify a way to help turn the decline around?"
Once you have got the problem statement right, inform the interviewer that you would like to ask a few clarifying questions to improve your understanding of the situation. There are many clarifying questions you might want to cover. Not all of them are relevant in each case, and some maybe very specific to some niche cases. Below is a structure that should help navigate and identify what questions you would want to ask in the majority of cases:

I have personally had a little trouble ensuring that the interviewer doesn't get bored or assume that I have started the case, while asking clarifying questions. Thus, I have put together the way in which I like to phrase and frame my clarifying questions, in order to minimise this confusion:

Structuring and Problem Solving

Once the clarifying questions have been asked, you should be in a position where you are very clear on what the end requirement is, and have a reasonable understanding of the space through which you have to navigate to get to this end requirement. From that point on, you're in the middle portion of the case. This is the real meat of the matter, where you keep structuring and deep diving, until you have arrived at a meaningful solution. In order to do this, there is a cyclic set of steps to be followed:

1. State the objective -

Right at the beginning of the case (after clarifying questions) you'll have an objective in mind, for eg. "identifying why the profits are down". It is crucial to ensure that at each step of the structure subsequently, you maintain such an objective in mind, and use it. For example, this objective might transform into "identifying why revenues are down", then "identifying why volume of sales is down" and so on. All of these objectives, if solved, will solve your original objective.
Now, the idea is to state the objective out loud, before getting started, so that the interviewer understands what is going on in your mind, and can also stop and help you along if the objective isn't perfectly on point. For eg. "We need to now understand why revenues have dropped over the last 6 months". Once you get deeper into a structure, it is possible that you'll make some unfounded assumptions along the way. It will be quite useful to keep getting your interviewer's buy-in without explicitly stopping and asking if what you're doing is correct each time.

2. Pause & structure -

Once you have stated the objective, you should ask for a little time to think through how you can structure the problem. For eg. "I'd like to take a minute to structure my thoughts, and see how we can break this up further". You might choose something more succinct, or whatever feels most natural and clear to you. Just make sure to communicate that you need a little time, and that you plan on structuring the problem.
Now, as you're structuring, use your learnings from the "Foundations" section page on "Structuring". The objective that you have just stated probably appears to you as a numeric problem, a process to be analysed, a qualitative analysis of a situation, a task being studied or done, or a selection of the best alternative. Basis which of the 5 categories it fits into, you'll be able to quickly ask yourself the right question and come up with an effective, MECE structure. Of course, my method of structuring through objective classification isn't fool proof, so hopefully you have refined this into your own approach which helps you quickly identify good, fitting structures.

3. Check on structure -

Once you have written out your structure, it is time to communicate it and check on whether the interviewer is okay with it, before proceeding. For pointers on how to describe your structure to the interviewer, reference the "Elaborating in <=3 points" under the "Communication" page in the "Foundations" section. Once you have called your structure out, you will want the interviewers guidance on which branches to focus on. Before this you should quickly ensure that they believe that your structure is MECE and a good way to structure the problem. Because you might not want to ask 10-15 times in a case if your structure is okay, you should find a sentence which gives the interviewer the cue, that they should stop you if they think this doesn't work, but also allows you to continue without the awkward repetitive question and pause. For eg. "If this structure seems like a good way to proceed, I would like to now go through each step and identify where the problem may lie". You could pause for just a second after this, and continue, as long as you aren't stopped. Something like this is more efficient and less annoying than "Does this seem like the right way to go?".

4. Hypothesise / deep dive -

Once you have laid out a structure, you have 3 different options to use it in order to find the relevant bucket to focus on:
  - Run through all the buckets to find out which ones are (most) relevant to the objective. For eg. "I would now like to go through each step of the process, to identify where the drop off in customer volume stems from"
  - Ask the interviewer if we have any information on which of the buckets is most relevant. For eg. "Do we have any information on whether the average prices reduced or whether the volume of sales went down?"
  - Hypothesise as to what the issue might be, and focus on that bucket. For eg. "My hypothesis is that the prices wouldn't have decreased, and therefore the volume of purchase might have dropped. Do we have any information to check on that hypothesis?"
Depending on the kind of situation and structure at hand, you should pick which of the above approaches of deep diving is best. When you can make a reasonable guess, based on some meaningful information, try to put forward a smart hypothesis. Do not however, make guesses. When you don't have sufficient information, use the first or second option to collect the required information.

5. Repeat -

Once you have deep dived, as above, you would have essentially identified the bucket to focus on. This inherently means that you have a more refined objective in hand again, and can repeat the above cycle.

Outside of the above cycle, every now and then it is recommended to throw in a slightly different step. Two important additional steps to keep in mind are:

Summarisation -

Every now and then, you will find something insightful, which you believe is going to figure somewhere in your final recommendation. At these points, you likely would have gone reasonably deep into your structure. This is a good time to throw in a quick summary. These summaries should still remain crisp. For example, "We identified that XYZ's profitability has been down for the last 6 months because costs have been driven up by increased expenditure on electricity at the new factory." There is no need to recap the structure used, or any of the other areas which you explored and didn't find anything actionable. This is also a good point to ask the interviewer if it would make sense for you to continue exploring for other possible reasons for decline in profitability, or whether you should start looking to identify potential solutions. It is unlikely that you will summarise more than 2-3 times in a case. If you are, you might be overusing the tool.

Solutioning -

Once you have identified a clear enough problem, you wouldn't want to break it down further. For eg. It doesn't make sense to say "I'd like to now structure and identify why covid capacity constraints at the stadium has led to lower footfall". At this stage, once you have summarised till the insight, you would want to start coming up with possible solutions. Here also you want to ask for a minute to come up with solutions, and structure the same, even if your solutions aren't 100% comprehensive. For eg. "Solutions could include increasing the revenue from ticket sales (which has fallen) or growing revenue from other sources". This structure is MECE, and within it you could embed a few creative ideas in each branch, even if you don't continue to be MECE and cover all possible solutions. The idea is to show some creativity and come up with solutions which could help.

Synthesis

The synthesis is the closing of the case. The idea here is to quickly capture the recommendation, and the reasoning behind it. A synthesis is distinctly different from a summary. The idea isn't to recap everything that we have learned. The idea here is to judge whether you can crisply capture the crux of the matter (so what). A synthesis should therefore follow the format of:
I believe that XYZ should do …. The reason that they should do this is:
1. Reason 1 and it's implication
2. Reason 2 and it's implication
3. Reason 3 and it's implication
Have a look at "Top down" in "Communication" in "Foundations" for a more detailed orientation.